Mobile and fixed network operators use various types of middleboxes or inline services to inspect and alter network traffic transiting through their network. These middleboxes, which will be referred to as services in this document, are transparent to the end users and provide functionality such as transparent caching, virus scanning, and deep packet inspection. These services are usually packaged and sold as dedicated appliances (either physical or virtual) and are often expensive.
Operators are facing a sharp increase in traffic demand and continue looking at new ways to monetize their network. Due to the high cost of service appliances, operators want to avoid matching the capacity of these services with this growth. Operators would rather have the ability to selectively direct traffic to specific set of services instead of forcing all traffic through every service. This ability would allow an operator to steer video traffic, which is a source of the recent traffic explosion, away from expensive services such as deep packet inspection, thus reducing the need for investing in new service appliances.
The ability to steer particular classes of traffic through predefined sets of services can also be used to enable new streams of revenue for operators. An operator could offer services such as virus scanning or content filtering to customers who elect to pay for such services.
A service chain, or path, is an ordered set of services. Traffic steering is the action of classifying traffic and directing the different classes of traffic through specific service chains. Three broad classes of solutions are used today to implement some form of traffic steering and service chaining.
The first approach is to integrate the services as part of an extensible router or gateway. An operator can add new services by adding additional service cards to its router or gateway.
The second approach is to configure one or more static service chains where each service is configured to send traffic to the next service in its chain. A router using Policy Based Routing (PBR) classifies the incoming traffic and forwards it to services at the head of each chain based on the result of the classification.
A third approach is to use a router using PBR, and for each service to be configured, to return traffic back to the router after processing it. The router classifies traffic after each service hop and forwards it to the appropriate service based on the result of the classification.
All three classes of solutions have drawbacks. The first approach does not support the integration of existing third party service appliances. This solution is proprietary and service vendors must port their applications to the software and hardware configuration supported by the router or gateway. This solution potentially suffers from a scalability issue as the number of services and the aggregated bandwidth is limited by the router's capacity.
The second approach does not support the definition of policies in a centralized manner and instead requires that each service be configured to classify and steer traffic to the appropriate next service. This approach requires a large amount of service specific configuration and can be error prone. The second approach also lacks flexibility as it does not support the steering of traffic on a per subscriber-basis and limits the different service chains that can be configured. Getting around these limitations would require additional configuration on each service to classify and steer traffic and automated ways to push these configurations dynamically as subscribers connect to the network.
The third approach also suffers from scalability issues as traffic is forced through the router after every service. The router must be able to handle N times the incoming traffic line rate to support a chain with N−1 services.
Therefore, it would be desirable to provide a system and method that obviate or mitigate the above described problems.